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DETAILED ACTION 

1 . This Action is in response to the Request for Continued Examination dated 
1/18/2007. Claims 54-90 are pending. Claims 54-90 are rejected. 

2. Amendments to the specification are noted. The objection to the specification 
is withdrawn. 

3. Remarks concerning the 35 U.S.C. 101 rejections are noted. However, the 35 
U.S.C. 101 rejections are maintained. Furthermore, new claim 90 is rejected under 35 
U.S.C. 101. 

4. Amendments to claim 58 to address the 35 U.S.C. 112, first paragraph 
rejection are noted. Remarks concerning the rejection of claim 86 under 35 U.S.C. 112, 
first paragraph are noted and found persuasive. The 35 U.S.C. 1 12, first paragraph 
rejections of claims 58 and 86 are withdrawn. New claim 90 is rejected under 35 U.S.C. 
112, first paragraph. 

5. Amendments to claims 58 and 86-89 to address the 35 U.S.C. 112, second 
paragraph rejections are noted. The 35 U.S.C. 112, second paragraph rejections of 
claims 58 and 86-89 are withdrawn. Remarks concerning the rejection of claim 64 
under 35 U.S.C. 112, second paragraph are noted and found persuasive. The 35 
U.S.C. 112, second paragraph rejection of claim 64 is withdrawn. Remarks concerning 
the rejection of claim 85 under 35 U.S.C. 112, second paragraph are noted and found 
persuasive. The 35 U.S.C. 112, second paragraph rejection of claim 85 is withdrawn. 
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6. Arguments regarding the 35 U.S.C. 102 rejections have been fully considered 
but are moot in view of the new grounds of rejection presented below. 

Claim Rejections - 35 USC §112 
The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 

7. Claim 90 is rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the written description requirement. The claim(s) contains subject 
matter which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventor(s), at the 
time the application was filed, had possession of the claimed invention. This is a 
new matter rejection. 

As to claim 90, the specification appears to support that the index structure is 
contained in a container, the container having a string repository, and a predetermined 
code value, but the specification does not appear to support the string repository not 
containing a string corresponding to the predetermined code value (emphasis added). 

Art rejection of the above claims is applied as best understood in light of the 
rejection under 35 U.S.C. 1 12 discussed above. 

» 

Claim Rejections - 35 USC § 101 

The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 
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8. Claims 54-90 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. 

As to claim 54, the claim contains an abstract idea (e.g., "locating and 
extracting"). Therefore, the claim must be drawn to a practical application of the 
abstract idea, which may be established through either a physical transformation or a 
useful, concrete, and tangible result. See MPEP 2106. 

The claim does not cause a physical transformation. For example, the steps of 
locating" and "extracting" are reasonably understood to one of ordinary skill in the art 
as merely data manipulation without actually producing any physical transformation 
(para, 132). 

The claim does not produce a useful, concrete, and tangible result. Merely 
"searching or extracting" is believed to be an abstract manipulation, failing to enable the 
"useful, concrete, and tangible" to be realized. The statement in the claim that recites 
an intended use or field of use (e.g., "for storage in the computer readable medium... for 
use in locating and extracting") may raise a question as to the limiting effect of the 
language in the claim. The claimed invention as a whole must produce a "useful, 
concrete and tangible result." Emphasis added. State Street, 149 F.3d at 1373-74, 47 
USPQ2dat 1601-02. See MPEP 2106. 

Also, the claim is drawn to nonfunctional descriptive material on a computer 
readable storage medium, which is non-statutory. Nonfunctional descriptive material in 
this case is a mere arrangement of data (various "sections" of data or various fields of 
data). See MPEP 2106. 
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As to claim 63, the claim is drawn to nonfunctional descriptive material on a 
computer readable storage medium, which is non-statutory. Also see discussion of 
claim 1. Nonfunctional descriptive material in this case is a mere arrangement of data 
(various "sections" of data). See MPEP 21 06. 

As to the other independent claims, see the discussion of claim 54 above. 

Dependent claims are rejected for failure to cure the deficiencies of the 
independent claims. 

Art rejection is applied in anticipation of Applicant amending the claims to 
overcome the rejection under 35 U.S.C. 101 above. 

Claim Rejections - 35 USC § 103 

The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 

9. Claims 54-84 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Evain (XP002323574) provided by Applicant, in view of Wan (US 
2004/0028049). 

As to claim 54, Evain teaches the following subject matter: 

(i) Index structure for metadata divided into fragments, the index structure 
contained in a computer readable storage medium (e.g., fig. 2-3, 1.1.1, 2.1.5, 2.2, 2.2.2, 
2.2.4, 2.3); 

A list of keys corresponding to fields of the metadata (2.2.2, 2.3.1.1, 2.3.2); 
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Location information for defining a key and locating and extracting a fragment of 
the metadata (see XPath section 2.3.1:1, 2.3.2, also see above). 
Evain does not expressly teach, 

(A) "wherein at least part of the location information defining the key is expressed 
as a predetermined code, the predetermined code being assigned to the at least a part 
of the location information according to a convention for associating codes with portions 
of the metadata." 

(A1) However, Wan teaches an encoder encoding values of attributes and 
elements of data types into more efficient representations according to their types (para. 
0054). Furthermore, elements can be referenced and located ("location information") 
using ID's or XPath fragments (para. 0077). In an encoding step, the fragment address 
is translated into an encoded form (a "predetermined code", para. 0092-0093). Note 
that the encoding is according to a convention for associating codes with portions of the 
metadata (e.g., see the XPath fragment that was encoded, see e.g., para. 0092-0093, 
0057-0058). 

(A2) Furthermore, Wan teaches that typically, a set of elements and attributes 
are repeatedly used in a document instance. Element names and attribute names can 
be assigned codes to reduce the number of bytes required to encode them (para. 
0049). 

(A3) Furthermore, Wan teaches using multiple encoding formats (conventions), 
for example, using no special or default encoding for 0-9 character strings, a default 
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encoder for 10-99 character strings, and a special encoder for 100+ character strings 
(para. 0057). These encoding formats correspond to a user defined type. 

(A4) Meanwhile, Evain teaches defining location information for a fragment and a 
key (see XPath section above and 2.3.2). The location information is expressed as 
XPath strings. Evain could support encoding location information above because Evain 
already uses encoding to encode another value (sec. 2.3.2, see the fields called "key 
encoding indicator" and "key encoding"). 

(A5) Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to modify Evain with the above from Wan, such that 
limitation (A) above is implemented for at least part of the location information string(s), 
and one or more of the location of the fragment and location of the key. Furthermore, 
depending on the length of the string, a special encoder may be used. Note that for a 
user defined 0-9 character strings, the encoding will be the original text string (in this 
case, an XPath address that is encoded in native text format). One motivation would 
have been to increase processing efficiency, as taught by Wan (para. 0093). Another 
motivation would have been to save memory, since a reduced number of bytes are 
required to encode elements and attributes (Wan, para. 0049). Finally, another 
motivation would have been to achieve compromise between decoding time and the 
level of compression (Wan, para. 0057). 

As to claim 55, Evain as applied above further teaches wherein the location 
information comprises location information of a fragment including the key, and location 
information of the key within the fragment (see XPath section above and 2.3.2). 
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As to claim 56, the combination of Evain/Wan above would teach or suggest 
wherein one of the location information of the fragment and the location information of 
the key is expressed as the predetermined code (see above discussion). 

As to claim 57, the combination of Evain/Wan above would further teach or 
suggest the code comprising additional information in a language for addressing parts 
of a markup language document (e.g., Evain's XPath), wherein the location of the 
fragments and key encoded as a predetermined code corresponds to a user defined 
type (e.g., a shorter string of 0-9 characters in Wan). Also see above discussion. 

As to claim 58, the combination of Evain/Wan above would further teach or 
suggest one of the location information of the fragment and the location information of 
the key expressed as the predetermined code (e.g., using a default/special encoding in 
Wan, see para. 0057 and above) and one of the. location information of the fragment 
and the location information of the key encoded in a language for addressing parts of a 
markup language document (e.g., Evain's XPath, see discussion above). 

As to claim 59, the combination of Evain/Wan above would further teach or 
suggest providing values of the keys and identification information concerning the 
metadata corresponding to the values of the keys for locating and extracting a fragment 
of the metadata (see e.g. Evain's use of the XPath above, and use of handles within the 
fragment structure, also see above). 

As to claim 60, the combination of Evain/Wan above would further teach or 
suggest a sub section comprising ranges of values of the key and identification 
information on ones of the fragments of metadata corresponding to the values of the 
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key (e.g., Evain 2.3.4), and a section comprising representative key values representing 
the respective ranges of values of the key (Evain 2.3.3). 

As to claim 61, the combination of Evain/Wan above would further teach or 
suggest wherein the list includes identification information on the section, and 
identification information on the subsection (Evain, 2.3.2 - 2.3.4). 

As to claim 62, the combination of Evain/Wan above would further teach or 
suggest wherein each of the representative key values is a value among the 
corresponding range of values of the key (Evain, 2.3.2-2.3.4). 

As to claim 63, Evain teaches the following claimed subject matter: 

Limitation (i) addressed above; 

a key index list section (fig. 2, 2.3.2) comprising a list of keys corresponding to 
fields of metadata and location information for defining the keys and extracting 
fragments of the metadata (see above, and sec. 2.2-2.4), a key index section (fig. 2, 
2.3.3), and a sub key index section (fig. 2, 2.3.4); 

Wherein for a key of the key index list: 

The sub key index section comprises ranges of values of the key (2.3.3, 2.3.4) 
and identification information on ones of the fragments of the metadata corresponding 
to the values of the key (see table in 2.3.4, e.g., "targetjiandle", 2.2.2, 2.2.4); 

The key index section comprises representative key values representing the 
respective ranges of values of the key (2.3.3). Also see above discussion of similar 
claimed subject matter. 

Evain does not expressly teach (A) discussed above, repeated here. 
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However, the complete discussion of paragraphs (A1-A5) is repeated here. 

As to claim 64, Evain as applied above further teaches wherein the location 
information comprises location information of a fragment including the keys, and 
location information of the keys within the fragment (see XPath section above and 
2.3.2). 

As to claim 65, Evain as applied above further teaches comprising a 
corresponding key index section and a corresponding sub key index section for another 
key of the key index list (2.3.2-2.3.4). 

As to claim 66, Evain as applied above further teaches wherein the key index 
list section further comprises identification information on the key index section and the 
key index section further comprises identification information on the sub key index 
section (2.3.2-2.3.4). 

As to claim 67, Evain teaches the following claimed subject matter: 

Limitation (i) above; 

A list of keys corresponding to fields of the metadata (2.2.2, 2.3.1.1, 2.3.2); 
Location information for defining a keys (see XPath section 2.3.1.1, 2.3.2, also see 
above). 

Values of the keys and identification information concerning the metadata 
corresponding to the values of the keys for locating and extracting a fragment of the 
metadata (see e.g. Evain's use of the XPath above, and use of handles within the 
fragment structure, also see above). 

Evain does not expressly teach (A) discussed above, repeated here. 
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However, the complete discussion of paragraphs (A1-A5) is repeated here. 

As to claim 68, Evain as applied above further teaches wherein the identification 
information comprises identification information on the fragments of the metadata 
corresponding to the values of the keys (e.g., 2.3, XPath, Key Index). 

As to claim 69, Evain as applied above further teaches wherein the metadata 
has the structure of metadata as defined by the TV Anytime Forum (see e.g., Evain, 
introduction, 2.3.1.1, 2.3.5). 

Claim 70 is drawn to substantially the same subject matter as claim 54, 
addressed above. 

As to claim 71, Evain teaches the following claimed subject matter: 

Limitation (i) addressed above, including "the index provided to search the 
metadata" (see throughout Evain); 

Providing a key index list section (fig. 2, 2.3.2) comprising a list of keys 
corresponding to fields of metadata and location information for defining the keys and 
locating and extracting a fragment of the metadata (see above, and sec. 2.2-2.4), a key 
index section (fig. 2, 2.3.3), and a sub key index section (fig. 2, 2.3.4); 

Wherein for a key of the key index list: 

The sub key index section comprises ranges of values of the key (2.3.3, 2.3.4) 
and identification information on ones of the fragments of the metadata corresponding 
to the values of the key (see table in 2.3.4, e.g., "targetjiandle", 2.2.2, 2.2.4); 
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The key index section comprises representative key values representing the 
respective ranges of values of the key (2.3.3). Also see above discussion of similar 
claimed subject matter. 

Evain does not expressly teach (A) discussed above, repeated here. 

However, the complete discussion of paragraphs (A1-A5) is repeated here. 

Claim 72 is drawn to substantially the same subject matter as claim 67, 
addressed above. 

As to claims 73, 75, 77, 79, 81, and 83, Evain further teaches wherein the 
location information to which the predetermined code is assigned corresponds to a path 
from a root node in the metadata to a metadata fragment containing the key (see Sec. 
2.3.1.1). 

As to claims 74, 76, 78, 80, 82, and 84, Evain further teaches wherein the 
location information is an XPath expression (e.g., see sec. 2.3.1.1). 

10. Claims 85-90 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Evain (XP002323574) provided by Applicant, in view of Wan (US 
2004/0028049), further in view of Hubbard ("Programming with C++"). 

As to claim 85, Evain teaches the claimed subject matter including: 

Limitation (i) as discussed above; 

As to "transmitted from provider to receiver", see sec. 2.1.5, 2.3.1.1, 2.3.2, and 
note that the data has to be transmitted from a provider to a receiver for the system to 
be functional in a computing environment. See previous Action. 
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Evain does not expressly teach comprising a fragment type field containing an 
encoded value assigned to a standard fragment type specifying a location of the 
fragment, wherein the encoded value is assigned to the standard fragment type 
according to a convention for specifying standard fragment types and a key descriptor 
field containing location information specifying a location of a key for the index relative 
to the location of the fragment indicated by the fragment type field. 

The complete discussion of paragraphs (A1-A5) is repeated here to show that it 
would have been obvious to one of ordinary skill in the art at the time the invention was 
made to encode values of location information of the fragment and the key. 

Evain and Wan as modified in the above paragraph does not expressly teach the 
fragment type field and key descriptor field, containing the encoded value. 

However, Evain teaches a program module containing various fields, including a 
pointer to a string (see e.g., table in 2.3.2). Hubbard shows a program module . 
comprising a string field (e.g., "ABCDEFG"). The string field could contain the encoded 
value when combined with Evain/Wan above. Furthermore, Evain could support 
encoding location information in the index list above because Evain already uses 
encoding fields to encode another value (sec. 2.3.2, see the fields called "key encoding 
indicator" and "key encoding"). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to further modify Evain/Wan with the above, such that the 
index list has a "fragment type" and "key descriptor" field containing encoded values of 
the fragment and key, respectively. Note that the encoded value is assigned to 
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standard (frequently used) fragment types, as seen in the discussion in A2. The 
motivation would have been to adapt to the particular requirements of the user in setting 
up the index of fig. 2. For example, a user may prefer a direct access to the encoded 
string instead of an indirect access. 

As to claim 86, the combination of Evain/Wan/Hubbard above would further 
teach or suggest wherein the encoded value is assigned to a predefined string prior to 
creating a container containing the index structure for transmission from the provider to 
the receiver, because if the encoding of the predefined string is to work properly (see 
e.g., Wan, fig. 3, and discussion above) the encoding must happen (e.g., Wan, para. 
0054) before the container is created and sent to the receiver, or else the receiver 
would be receiving a non-encoded version of the data, and/or the decoder would not be 
able to decode the contents of the container. Note, similarly, that Wan encodes the 
data first, and then transmits the resulting data structure(s) to a receiver (e.g., fig. 3-4, 
para. 0053). 

As to claim 87, the combination of Evain/Wan/Hubbard above would further 
teach or suggest wherein the predefined string specifying the fragment location is a path 
from a root node in the metadata to a metadata fragment containing the key (see 
Evain'sXPath 2.3.1.1). 

As to claim 88, Evain as applied above further teaches the claimed subject 
matter (see XPath section above). 

As to claim 89, Evain as applied above would have the structure of metadata as 
defined by the TV Anytime Forum (see e.g., introduction, 2.3.1.1, 2.3.5). 
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As to claim 90, Evain as applied above further teaches wherein the index is 
contained in a container, the container having a string repository (see fig. 2). The 
combination also teaches or suggests encoding the string for efficiency (see above). 

Evain, Wan, and Hubbard do not expressly teach wherein the string repository 
does not contain a string corresponding to the predetermined code value. 

However, Evain teaches a program module containing various program 
components, including a pointer to a string (see e.g., table in 2.3.2). Hubbard shows a 
program module already comprising a string (e.g., "ABCDEFG"). See above. 

Additionally, it has been held that making integral is obvious. In re Larson, 340 
F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965). 

In this case, the key index list and the string in Evain's string repository are 
initially "separate" (see table in 2.3.2 and fig. 2). 

Furthermore, it has been held that the omission of an element and its function is 
obvious if the function of the element is not desired. In re Larson, 340 F.2d 965, 144 
USPQ 347 (CCPA 1965). 

In this case, the string in the string repository discussed above could be omitted if 
it and its function are not desired. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to further modify Evain/Wan/Hubbard with the above such 
that a "one piece construction" of the key index list/string is used. In the combination, 
the string would be directly recorded in the key index list module similarly to Hubbard's 
string, which was directly recorded within a program module. Furthermore, it would 
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have been obvious to one of ordinary skill in the art at the time the invention was made 
to omit the string in the repository since the string and its function would no longer be 
required (because the string would already be present in the key index list). Therefore, 
the string repository would not contain a string corresponding to the predetermined code 
(see above) as claimed. The motivation would have been to adapt to the particular 
requirements of the user in setting up the index of fig. 2. For example, a user may 
prefer a direct access to the string instead of an indirect access. 
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Conclusion 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Charles E. Lu whose telephone number is (571) 272- 
8594. The examiner can normally be reached on 8:30 - 5:00; M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Apu Mofiz can be reached at (571) 272-4080. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



CL 

Assistant Examiner 

AU2161 

2/16/2007 




